A contract-based method to specify stimulus-response requirements

A number of formal methods exist for capturing stimulus-response requirements in a declarative form. Someone yet needs to translate the resulting declarative statements into imperative programs. The present article describes a method for specification and verification of stimulus-response requirements in the form of imperative program routines with conditionals and assertions. A program prover then checks a candidate program directly against the stated requirements. The article illustrates the approach by applying it to an ASM model of the Landing Gear System, a widely used realistic example proposed for evaluating specification and verification techniques. Keywords—Seamless Requirements, Design by Contract, AutoProof, Eiffel, Landing Gear System I. OVERVIEW AND MAIN RESULTS The present article describes a technique for specification and verification of stimulus-response requirements using a general-purpose programming language (Eiffel) and a program prover (AutoProof [1]) based on the principles of Design by Contract [2]. Real-time, or reactive, systems are often run by a software controller that repeatedly executes one and the same routine and it is specified to take actions at specific time intervals or according to external stimuli [3]. This architecture is reasonable when the software has to react timely to non-deterministic changes in the environment. In this case the program should react to the external stimuli in small steps, so that in the event of a new change it responds timely. Computation tree logics (CTL) [4] represent a frequent choice when it comes to capturing stimulus-response requirements. Although it may be easier to reason about requirements using declarative logic like CTL, the reasoning may be of little value for the software developer who will implement the requirements. Mainstream programming languages are all imperative, and the translation between declarative requirements and imperative programs is semi-formal. Requirements have to be of imperative nature from the beginning. This would bridge the gap in how customers and developers understand them. For a software developer it is preferable to reason about the future program without switching to an additional formalism, notation and tools not connected to the original programming language and the IDE. The present article describes a technique to achieve this goal, in particular: • Introduces the Landing Gear System (LGS) case study and the LGS baseline requirements (Section II). • Generalizes the LGS baseline requirements, maps them to a well-established taxonomy, and complements the taxonomy (Section III). • Provides a general scheme for capturing semantics of the stimulus-response requirements in the form of imperative program routines with assertions (Section IV). • Exercises utility of the approach by applying it to an Abstract State Machine (ASM) specification of the Landing Gear System case study (Section V). • Concludes the possibility of statically checking a sequential imperative program directly against a stimulus-response requirement whose semantics is expressed in the same programming language through conditionals, loops, and assertions (Section VII). Application of the technique leads to discovery of an error in the published model of the LGS ASM [5]. The error is not present in the specification the authors have actually used for proving the properties, but the error has found its way into the publication. II. THE LANDING GEAR SYSTEM Landing Gear System was proposed as a benchmark for techniques and tools dedicated to the verification of behavioral properties of systems [6]. It physically consists of the landing set, a gear box that stores the gear in the retracted position, and a door attached to the box (Figure 1). The door and the gear are actuated independently by a digital controller. The controller reacts to changes in position of a handle in the cockpit by initiating either gear extension or retraction process. The task is to program the controller so that it correctly aligns in time the events of changing the handle’s position and sending commands to the door and the gear actuators. III. STIMULUS-RESPONSE REQUIREMENTS The LGS case study defines a number of requirements, including several for the normal mode of operation (Figure 2). ar X iv :1 70 4. 04 90 5v 1 [ cs .S E ] 1 7 A pr 2 01 7 Fig. 1. Landing set (source: [6]). (R11bis)When the command line is working (normal mode), if the landing gear command handle has been pushed DOWN and stays DOWN, then eventually the gears will be locked down and the doors will be seen closed. (R12bis)When the command line is working (normal mode), if the landing gear command handle has been pushed UP and stays UP, then eventually the gears will be locked retracted and the doors will be seen closed. (R21) When the command line is working (normal mode), if the landing gear command handle remains in the DOWN position, then retraction sequence is not observed. (R22) When the command line is working (normal mode), if the landing gear command handle remains in the UP position, then outgoing sequence is not observed. Fig. 2. Baseline LGS requirements. The requirements communicate a common meaning of the form: • If stimulus holds, then response will eventually hold in the future. For requirement R11bis, stimulus⇔“The operation mode is normal and